COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	future[w88,jmc]		The future of LISP
C00003 00003	A FEW NOTES ON THE FUTURE OF LISP
C00008 ENDMK
C⊗;
future[w88,jmc]		The future of LISP

1. cleanup

2. higher order

3. combination with logic programming

4. in combination with proof system and program
transformation system

A FEW NOTES ON THE FUTURE OF LISP

John McCarthy, Stanford University

	I must confess that I find myself with a lack of concrete and
ambitious ideas about the future of LISP.  Here are a few, however.

	1. Common LISP represents a reasonable standardization of present
practice, but it's overly complex.  A cleaned up LISP is desirable,
perhaps starting from Scheme.  At first it should be the work of one
person or a small group --- not a committee representing diverse
interests.  I don't know whether the present efforts in that direction
will lead to a consensus.  If there is to be a co-operative effort, it
shouldn't have a fixed time scale, and it should not be in competition
with Common LISP standardization now.  The phenomenon to avoid is what
might be called academic logrolling in which I'll agree to put your bright
idea in if you agree to put in mine.  This is what has made previous
committee designed languages unsuccessful.  It partially affects Common
Lisp, but the enormous effort of communication and implementation has
mitigated its effects.

	2. Allowing higher order functions should provide the possibility
of much greater generality.  However, I don't know how to use them to get
substantial advantages in actual programming.

	3. Combining LISP with logic programming offers advantages that
many people are exploring.  However, it seems to me that the following
difficulty has limited success so far and may even be fundamental.
Regarded semantically, a pure LISP program may be regarded as a collection
of equations characterizing some functions.  Likewise a Prolog program may
be regarded as a collection of sentences characterizing some predicates.
It is reasonably straightforward to allow both notations getting some
sentences characterizing both functions and predicates.  However, LISP
taken by itself not only characterizes some functions but it also provides
definite evaluation rules, e.g. call-by-value and call-by-name that
compute these functions reasonably efficiently.  Likewise Prolog has a
reasonably efficient standard evaluation rule, although more care has to
be taken with Prolog than with LISP to write the program in such a way
that the evaluation is successful an efficient.  The catch is that there
doesn't seem to be a good standard evaluation rule for a LISP-Prolog
mixture.  Maybe one can be found.

	4. There are good theoretical prospects for combining LISP with a
proving system and with a specification transformation system that would
yield programs that automatically meet specifications.  I think it won't
amount to using the specifications as a programming language, because the
user will have to specify how the specifications are to be transformed
into a program.

	5. Another way of putting the previous point is to say that major
improvement in language will probably require new ideas for separating
logic and control.